Can you please provide context, did the mentioned mentor agree to mentoring, and did you submit a proposal though summer of code website yet - we're nearing the final deadline very soon.

We did an offline review. This is no more draft. I will submit the proposal to Google today.

Has @lhoward confirmed he would be available to mentor this project?

As org admin I need to be able to confirm the availability of the mentor as we get such new project ideas. I'll reach out to Luke directly.

Hello! When I first was pinged on this I wasn't aware of the 3-5 hour/week time commitment. 15 minutes is probably all I could manage. So I'm going to have to decline unfortunately unless that mentor time commitment works.

However if @xavgru12 is planning to this regardless of GSoC I'm happy to review PRs, etc, as time permits.

Thanks for confirming Luke.

So as unfortunate as it is, we do not have a confirmed mentor for the project. That's the risk that comes with proposing new original project ideas so close to the GSoC deadline. If you'd find a mentor from the Swift project willing to carry the project we could reconsider, but otherwise it seems we can't consider this project @xavgru12

@finagolfin
Given your interest and dedication to builds/cross compilation as well as your reviews of Jesse‘s pull requests, you would be a great mentor

If @lhoward is willing to mentor together- him for the embedded/Yocto side, me for the Swift cross-compilation side- that might work. Otherwise, I don't know enough about Yocto and tools like bitbake, having never used them, for me to be the mentor alone.

I would say most of the work is on the Swift side.
I would like to solve the cross-compilation issues inside Swift‘s build-scripts for everyone. Yocto is supposed to be a wrapper around that and pretty straightforward.
Do you agree that most of the work is inside Swift? @lhoward

If @lhoward is willing to mentor together- him for the embedded/Yocto side, me for the Swift cross-compilation side- that might work. Otherwise, I don't know enough about Yocto and tools like bitbake, having never used them, for me to be the mentor alone.

I thought about it a bit and discussed with my wife as well and she thinks it's a good idea. I have already been doing Swift for Embedded Linux things and struggling due to a lack of time, but the desire is still there. @finagolfin if you are willing to mentor on the Swift/scripts side then I should have a couple of hours a week to dedicate to the Yocto/embedded Linux side of things.

So @ktoso I can commit to being a mentor here!!

@finagolfin
What do you think about you mentoring the Swift side and Jesse mentoring the Embedded Linux side?

Just for clarification the title is Swift for Embedded Linux in order to mention the end goal.
However the work is really in Swift improving cross compilation. Others apart from this may see the benefits of an improved build-script as well.
When we get to the point where cross compilation is smooth, we can leverage this in Yocto establishing a meta layer.
Using this meta layer we can set up a CI in swiftlang/swift in order to prevent regressions being forgotten.
By that we are at the point of officially supporting Swift for Embedded Linux, which is a massive market to expand to.

@finagolfin
What do you think about you mentoring the Swift side and Jesse mentoring the Embedded Linux side?

Sounds good to me, I've sent you both an email asking for some more info about yourselves.

It is important to introduce the reader to any concepts in the idea, including links as necessary, and use the same format as the others. I've tried to help you do that with my review comments.

@finagolfin
I went through your comments. Have a look again now

@ktoso

Can we get this PR merged?

@swift-ci please test

At this moment I don't think we're comfortable with this project's mentorship status.

It is not clear to me we have a 100% dedicated mentor who can spend the three months of required 3-5 hours weekly to guide this project, and the projects scope is somewhat unclear to me even after consulting it with Embedded Swift experts @kubamracek, @rauhul and @lhoward. The exact work to be done in this project is not clear to me, nor is the scope e.g. is this truly a 350hours project?

This could perhaps be alleviated but it would be much better if such new project ideas were posted much earlier in the process, rather than just before application deadlines.

Having that said, merging this PR does not have any impact on accepting or not accepting a proposal.

It is all about the proposal submission you need to do on the summer of code website, which then are reviewed by mentors and the Swift leadership team. So either way you can submit your proposal idea and we'll give it consideration among the other ideas.

I'd also much rather have this discussion about clarifying if this project has a dedicated mentor or not on the Swift forums, rather than on a pull request, so if we are to continue hashing out if this project has a mentor it'd be better to continue over here: https://forums.swift.org/t/gsoc-2025-swift-for-embedded-linux/79031/

--

My suggestion for next steps:

Please submit your proposal on http://summerofcode.withgoogle.com as all submissions have to go through this flow. We will include it in review and include the potential mentors in reviewing the actual proposal and not just this idea draft. We may be able to consider it, but it will have to be weighted against all other existing proposals in a fair way.

Mentors would need to very concretely state their time and effort availability and understanding of the expectations about delivering the project. We should also be very specific where the contributions would be done, and include this in the proposal writeup.

Thanks in advance and I hope this helps,

I do not see it being late because I did a post in the Swift Forums a week ago:
https://forums.swift.org/t/gsoc-2025-swift-for-embedded-linux/79031

I thought that Howard would be my mentor and I pushed forward this route with him.

What is not clear? I do not see the missing parts as I talked a lot about it both in Forums as well as here.
I included links and stated that most of the work is in the build scripts, as well as meta-swift to conclude this project.

In the end it is up to you and Google to decide about this proposal.

I am doing my best to have a good proposal and mentors available.

The name Embedded Linux may be misleading(however is the correct name for this) since it is more about Linux than Embedded and as I stated Embedded Swift is unrelated to this.

I have not talked to the first two Embedded Swift experts, nor did they comment on the Forums post, nor have I seen them on the meta-swift repository. I talked with Howard and he knows about this, as I proposed him as my mentor before he reclined. I do not think this is still unclear for Howard.

Someone who has worked on Swift for Embedded Linux and got it to run is @xtremekforever

@ktoso if you check one of his blog posts:

https://medium.com/@jesselzamora/cross-compiling-swift-5-10-1-for-linux-armv7-b15986c0f1bf

He might be considered as an expert as well.

I have requested we continue discussions on the forums, let's please do that if you have further questions.

At this point though, I think we should just follow the normal review process of the actual proposal which must be submitted to the gsoc website. It should include a detailed timeline of the project, goals and milestones along with details about what and where will be implemented.

The proposal will be subject to review as all other gsoc projects.

This PR is not a project proposal, it has far too little information to be considered a proposal. Please read the contribution guide which explains how a proposal should look like.

@ktoso should we close this PR? Looks like the deadline for the proposal has passed.

Yes, let's close this. The proposals actually submitted to the GSoC page are the actual "source of truth" anyway, so this isn't load bearing if it is here or not.

Thank you for sending in your idea folks!